Use $transaction() with a callback for interactive transactions where each step depends on the previous result. Use the array form for sequential independent operations that must be atomic but do not reference each other's results. Pass isolationLevel and timeout options for fine-grained control.
Interactive transactions (callback) — use when each step depends on the result of a previous step.
Sequential transactions (array) — use for truly independent operations that must commit or roll back together.
In interactive transactions, always use the tx client — using this.prisma inside the callback bypasses the transaction.
maxWait controls how long to wait for a connection; timeout controls the transaction duration limit.
Nested interactive transactions are supported in Prisma 5+ via savepoints.
We need to create an order and its line items in one API call. How would you use Prisma in a NestJS service to make sure both inserts succeed or both are rolled back?
If you start a Prisma transaction but forget to await the promise, what would the NestJS request return and why?
Show me how you would inject the Prisma client into a NestJS controller and begin a simple transaction.
A feature updates a user's balance and writes a transaction record. Midway through, the balance update fails validation. How would you structure the code so the whole operation rolls back?
During load testing, many concurrent requests start Prisma transactions and you see deadlocks. What strategies could you apply to reduce or avoid those deadlocks?
You moved some logic into a separate NestJS service that calls an external microservice inside a Prisma transaction, and now the transaction fails. Why might that happen and how would you fix it?
Design a pattern that lets multiple NestJS modules (Order, Inventory, Notification) share the same Prisma transaction context. What trade‑offs does your design have?
How would you add retry logic for transient failures inside a Prisma transaction without causing duplicate writes?
Discuss the performance and memory implications of using a request‑scoped PrismaService for transactions under high concurrency.
Our monolith is being split into several microservices, each with its own Prisma client. How would you migrate existing cross‑entity transactions to a distributed transaction model while preserving data integrity?
At thousands of QPS, what architectural changes would you consider for transaction handling in NestJS with Prisma to avoid bottlenecks?
How would you set up monitoring, alerting, and team policies for transaction failures across services that use Prisma?